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ABSTRACT 

Ongoing work at National Aeronautics and Space Administration Goddard Space Flight Center 
(NASA/GSFC), seeks to apply standard Internet applications and protocols to meet the technology 
challenge of future satellite missions. Internet protocols and technologies are under study as a future 
means to provide seamless dynamic communication among heterogeneous instruments, spacecraft, 
ground stations, constellations of spacecraft, and science investigators. 

The primary objective is to design and demonstrate in the laboratory the automated end-to-end 
transport of files in a simulated dynamic space environment using off-the-shelf, low-cost, 
commodity-level standard applications and protocols. The demonstrated functions and capabilities 
will become increasingly significant in the years to come as both earth and space science missions fly 
more sensors and the present labor-intensive, mission-specific techniques for processing and routing 
data become prohibitively. 

This paper describes how an IP -based communication architecture can support all existing operations 
concepts and how it will enable some new and complex communication and science concepts. The 
authors identify specific end-to-end data flows from the instruments to the control centers and 
scientists, and then describe how each data flow can be supported using standard Internet protocols 
and applications. The scenarios include normal data downlink and command uplink as well as 
recovery scenarios for both onboard and ground failures. The scenarios are based on an Earth orbiting 
spacecraft with downlink data rates from 300 Kbps to 4 Mbps. Included examples are based on 
designs currently being investigated for potential use by the Global Precipitation Measurement 
(GPM) mission. 
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INTRODUCTION 

The goal of an Internet data delivery approach is to provide the simplest, most cost-effective 
delivery of science data when and where needed. The Operating Missions as Nodes on the Internet 
(OMNI) Project at Goddard Space Flight Center (GSFC) has been demonstrating these concepts and 
working with future missions to baseline these approaches. The key issues for future National 



Aeronautics and Space Administration (NASA) missions have less to do with protocols and more to 
do with basic communication problems* 


Over the past 40 years, NASA has gone from developing and operating custom solutions to adopting 
commercial off-the-shelf (COTS) products and industry standard solutions. There was a time when 
NASA drove both space and ground communication technologies. The NASA need to move large 
volumes of data reliably over noisy channels in a time-critical environment was out in front of any 
other organization. Now, with the explosion of growth in commercial terrestrial communications, the 
space community has the opportunity to use technologies into which the private sector has poured 
billions of dollars. NASA Communications (Nascom) has demonstrated the value to NASA in 
changing to IP on the ground. The opportunity now exists for NASA to complete this transition in 
space. 

This paper will briefly describe the methods and protocols that NASA previously used to 
communicate with its spacecraft. The discussion then describes newer approaches, some of which 
are being studied under contract for the GSFC for the Global Precipitation Measurement (GPM) 
mission. This possible GPM approach uses standard Internet technologies and protocols to support 
all aspects of data communications with the spacecraft. 

NASA/GSFC LEGACY MISSION SUPPORT INFRASTRUCTURE 

NASA initially used a communications backbone that consisted of specially developed hardware and 
software components. This legacy system required constant monitoring to support all of the on-orbit 
missions. Installing new features required extensive development and testing efforts. The Nascom 
group provided the support personnel who were responsible to continually manage the lines and 
circuits to ensure that the operations team could communicate with the spacecraft on an as-needed 
basis. As can been seen from Figure 1, as Nascom moved to more standard protocols the throughput 
capacity increased, allowing Nascom to support missions with progressively higher data rates. 

Earlier NASA missions employed an old style tape recorder to store science and housekeeping data. “ 
When the spacecraft was in contact with a ground station, the recorder was commanded to rewind 
and begin a playback. With the advent of the next generation of missions, NASA moved to a space- 
qualified solid-state recorder (SSR), but the SSR still emulated the older style tape recorders. With 
either of the previous data storage techniques, there was no concept of files; the data was simply 
stored on-board as a stream of data. Whenever a station contact occurred, the operations team would 
request a data downlink based upon the on-board computer’s addressing scheme. 

Under the legacy mission domain, a major concept was that the telemetry downlink formats and 
protocols were different from those in the corresponding command operations procedures (COP) 
protocols 1. These different formats and protocols had to be tested prior to launch to ensure that the 
spacecraft had been successfully checked out. Under this approach, the telemetry downlink was used 
to provide a return link to verify that the commands were received in the correct sequence. To 
correctly design this type of an approach, unique application SW was required both on the ground 
and on the spacecraft to ensure that commands were not received out of sequence. This unique 
application code also required extra test time to ensure that the code worked as designed. Figure 1 
identifies the underlying data delivery protocols that Nascom has used since the early 1960s as well 
as the network throughput capacity using these protocols during that period. 


,-700 


NASA Network Backbone Capacity 

(2000) ATM Core Deployment 

OC-12 expandable to OC-48 
(1998) IP Upgrade / Expansion 
lOBaseT, 100BaseT, 
lOOOBaseT, orFDDI 
(1995) SCD andPTP Development 
begin IP Transition 

(1989) 4800 Bit Block TDRSS Format 
(1978) 4800 Bit Block MSS Format 
(1960) TTY Systems/Clock & Data 



-600 t? 

II 

_500 % 

3 s- 
g G, 

-400 P g 
£ Is 

-300 Q I 1 
_200 

-100 

_0 



ill Standards Based Systems 
B Transition Systems (jG r 1 

0 Legacy Systems 



Figure 1. NASA Data Delivery Protocols - Evolution and Throughput Capacity Upgrades 


NASA/GSFC NASCOM TRANSITION 

As indicated in Figure 1 , Nascom began an evolution towards a ground-based IP routing mechanism 
by developing and deploying the small conversion devices (SCD) and programmable telemetry 
processors (PTPs). These devices supported the use of IP for the ground transport of data; however, 
at that time there still were no modifications to the spacecraft or ground systems. After the IP 
transition (which could be regarded as a watershed event), Nascom ultimately supported a dramatic 
increase in the overall data throughput rates. Another benefit of the IP transition was that Nascom 
could now more thoroughly use commodity-level standards and COTS HW solutions to transport 
the data received at a ground station. However, the basic spacecraft and ground systems were still 
based on the legacy concepts; NASA/GSFC had not incorporated Internet protocols in a complete 
end-to-end approach. 

This all changed in the mid-1990s; NASA/GSFC began funding concepts and prototyping efforts to 
explore the use of a full IP-based communications protocol for space missions. This approach is 
leveraged against the Open Systems Interconnection (OSI) seven-layer reference model for data 
communications as noted in Figure 2. The OMNI Project at GSFC provided a focal point not only 
for IP-based prototyping to identify concepts, rationale, and requirements for the full use of IP for 
space missions but also for testing and evaluating the various IP-based approaches and solutions. 
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Figure 2. OSI Reference Model for space missions 


POTENTIAL NEW APPROACH FOR GPM 

In 2002, the OMNI Project began studying data system concepts for the GPM mission to identify 
and document how IP could be used in both the space segment and the ground segment. The essential 
objective was to route data from the instruments on-board the spacecraft all the way to the end users 
at either the mission operations control center or any group of science users. The GPM mission 
architecture, data flows, and concepts are described in greater detail in the draft Global Precipitation 
Measurement (GPM) Spacecraft and Instrument Telemetry Data Flow Interfaces and Operations 
Concepts document [2]. A draft spacecraft architectural system, as depicted in Fig. 3, was identified 
to support the GPM mission. This architectural concept employs fault-tolerant concepts with dual 
Ethernet Local Area Networks (LANs), dual on-board computers (OBCs), and dual up/down cards 
that also perform more routing functions. 

A major shift for the GPM mission is to replace the storage concept, since the GPM spacecraft will 
be designed with a modem operating system that supports file management. The GPM spacecraft 
will store the science data as files rather than storing the data as a stream onto a SSR. Another 
conceptual change under review is the data transport mechanisms used to support the spacecraft data 
transfer (both uplink and downlink of data). A fully redundant Ethernet LAN is being considered to 
support data transfer between the science instruments, the on-board computers (OBCs), and the 
up/down cards using UDP/IP packets to transport the data. A MIL-STD 1553 data bus is used as 
the data transport mechanism among other spacecraft subsystems using the current data packet 
concepts (e.g., between the attitude control subsystem and the OBC). The GPM spacecraft may use 
the Multicast Dissemination Protocol (MDP) [ 3 ] applications task, which guarantees reliable data 
file delivery over a variety of link types, either infrequent return links or full duplex links. 

Additionally, the OMNI Project suggested the use of High-Level Data Link Control (HDLC) framing 
for the link layer for the space-ground RF transmissions. The proposed use of HDLC is not 
considered risky, because HDLC is the dominant link layer standard in terrestrial networks. Further, 
currently there are eighty spacecraft that currently employ this link layer framing technique. GSFC 
has funded additional studies on the use ot jhjjjlC as a link framing technique on noisy space links; 
including a study completed by ITT Industries on the use of HDLC framing compared to CCSDS 
framing; these studies and results can be found on the OMNI web site [ 4 ], The OMNI Project also 




proposed that the GPM mission use a standard router at the ground station with the corresponding 
IP mobility and security protocols enabled. 
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Figure 3 - Proposed Architectural Concepts for GPM Spacecraft 
On-board science data transport concepts 

The science instruments format their data into UDP/IP packets for transport to the OBC via the 
Ethernet LAN; the real-time housekeeping data are sent to the OBC via the MIL-STD 1553 bus. In 
the OBC, the science data are removed from the UDP packets and stored into files. These files 
normally contain one minute’s worth of science data; but the OBC can be commanded to use 
different time slices to handle different situations, like a TDRSS handover. The OBC contains a 
storage management (SM) task, which provides file management for the spacecraft. It opens new 
files, adds the data from real-time UDP packets into the files and then closes the files when the 
maximum time limit, usually one minute, is reached. The SM task then moves the file into the “hot 
directory” for MDP to begin the associated processing to downlink the file. In this example, MDP 
acts as the initiator of the file transfer to the ground. 

Data downlink from spacecraft to ground station 

The data downlink consists of both real-time housekeeping data in UDP/IP packets and the science 
data files downlinked using an MDP server task on the spacecraft. These application data, both real- 
time and science data are inserted into UDP/IP packets with the appropriate header formats, 
including the Ethernet, IP, and UDP headers. The data are transferred to the up/down card/router. 
The up/down card throttles the data to the I and Q channels at an average rate of 150 kbps. When 
required, the mission operations center (MOC) can schedule an S-band single access (SSA) pass to 
provide an increase to the downlink rate and provide the capability of downlinking a large volume of 
data in a short period of time. The MOC would schedule an SSA pass in the event that there is a 
backlog of science data on-board the spacecraft occurring from a long TDRSS outage (over thirty 
minutes in duration). Shorter TDRSS outages will be handled by the excess bandwidth within the 
multiple access (MA) link. 



The router or up/down card extracts the application data from the Ethernet header and checks the 
UPD/IP header fields and determines that the data are external to the local network. The up/down 
card is responsible for adding the link layer header/trailer artifacts. The data are inserted into a new 
packet using an HDLC header frame and “bit stuffed” to mask any application data patterns that 
could match the HDLC one-byte flag pattern; this bit stuffing ensures that the HDLC flag byte can 
be used as a frame delimiter. An OMNI Project study using three current NASA missions (WIND, 
POLAR, and SOHO) concluded that the bit-stuffing overhead averaged approximately 1% for the set 
of sample science data. Additional details are presented in the OMNI paper [5] HDLC Link Framing 
for Future Space Missions. 

The data are converted into a serial stream for transmission by the antenna to the ground site. At the 
ground station antenna, the data are received as a serial stream and transferred to a local router. The 
router strips and processes the HDLC frame header/trailer fields (e.g., the frame sync and the CRC 
information), checks the UDP/IP header information to determine the next destination for the data 
and begins the routing process for an eventual transmission of the data to that address. On the 
ground, the standard protocols are used to route the spacecraft’s housekeeping data to the control 
center or any other desired location. On the ground, the routers continually monitor the data quality 
by checking the HDLC/Ethernet CRC information as well as the IP checksum and UDP checksum 
fields. The checks using these fields ensure that only “good quality” data are transmitted; no “bad 
quality” data would be transmitted to the end-user. 

MDP is a reliable file transfer application built upon UDP and is one of many current applications 
used to support a reliable multicast transport (RMT) protocol. The Internet Engineering Task Force 
(IETF) has chartered a working group, the RMT WG, to standardize reliable multicast transport 
protocols for “one-to-many bulk data” transport. Additional details on the roles, responsibilities, and 
charters of the RMT WG are contained on the IETF web site [6], 

The OMNI group is currently prototyping an MDP based approach for a reliable file transfer to 
support a space to ground transfer of the on-board files. With MDP, minimal, or no, operator 
intervention is required to downlink stored files. The OBC contains a storage management (SM) task, 
which acts as the initiator of the data transfer when a file is complete with its allotted science data. 
The SM task will put the science data file into the MDP’s “hot directory”, which triggers MDP to 
begin processing this file for downlink to the ground station. The MDP application will segment the 
science files into one Kbyte packets; MDP sends these 1 -Kbyte packets to spacecraft’s up/down 
card where the identical processing as discussed previously is done. Once on the ground, the data are 
routed using the original destination information, as sent from the spacecraft. The real-time 
spacecraft data are forwarded to the MOC and used to monitor and trend the health and safety of the 
spacecraft and instruments. At the ground station, a variety of options are available to disseminate 
the science data, including file storing and forwarding, forwarding data as UDP packets to one central 
location, or multicasting these UDP science packets, or any combination of these options. 

As one of the scenarios, the data initially could be transferred to a client MDP task on the ground 
station. This MDP client task reassembles the 1 -Kbyte packets into a copy of the original file and 
maintains the responsibility for ensuring data completeness by transmitting the necessary 
acknowledgments or negative acknowledgments. This MDP client task provides a post-processing 
option that enables this file to be transferred to any required user or group of users. As an alternative 
example, the real-time science data initially bypass the MDP client and are automatically routed to 
all science users who need the data for real-time displays. The data also are routed to the MOC (or 
any other central location) where again the MDP client task reassembles the 1 -Kbyte packets into 
the copy of the original file and performs the necessary processing to ensure data completeness. 
These data routing alternatives are examples of the ways in which the mission engineering trade space 
is opened up through the use of standard networking technologies and protocols. 


Real-time TCP/IP commanding 


Under the proposed approach, the spacecraft becomes a mobile node on a network and becomes 
attached to that network successively at the different ground stations. Advanced groups in private 
industry are currently addressing a similar issue in relation to wireless networking for cars, laptops, 
personal digital assistants (PDAs), and a multitude of other electronic devices that will be mobile and 
require IP network access. The IETF is currently working to establish the standards, practices and 
applications for wireless networking for mobile nodes. 

GPM is considering the proposed use of standard mobile IP protocols to support the forward link 
required for a TCP/IP connection for real-time command delivery. The router located at the station 
will have both mobile IP and IP security protocols enabled to support the GPM mission. The router 
will act as the foreign agent and advertise its availability; this agent advertisement will be scheduled 
to occur several seconds before the actual time that the forward l ink is scheduled to begin. Within a 
matter of seconds and with a minimum of 2-3 packets, the spacecraft and the MOC have established 
a tunnel by which data from the MOC can be uplinked to the spacecraft. This uplink data consists of 
command data, the MDP ACK list and the MDP NACK list. The command data are used to 
continue spacecraft and instrument operations and to maintain the health and safety of the mission. 
The NACK list is used to request retransmission of missing data while the ACK list is used to 
confirm the successful receipt of the data file at the MOC. 

UDP/IP for commanding in the blind 

The non-reliable data transport for command data is accomplished using a connectionless UDP 
session. This is similar in concept to what is done to support current mission with CCSDS blind 
commanding. In this scenario, no mobile IP routing is established since by definition, mobile IP 
implies a two-way connection. For blind commanding, it is necessary to establish a forward link to 
the spacecraft to uplink some type of data (commands). Instead of mobile IP and the agent 
advertisement that would be performed by the ground station routers, the MOC manually 
establishes a tunnel to a specific ground station router; this would be analogous with the approach 
that the MOC’s currently use to establish a session with a specific station/antenna as part of the 
pre-pass setups. The process can be automated to occur several minutes before a station contact, or, 
in the event of a critical spacecraft problem, the FOT can command it to occur when a station can 
communicate with the spacecraft. Once the tunnel is established between the MOC and the ground 
station, the command data are transmitted to the station in UDP packets. 

Fail-over and recovery scenarios 

GPM has considered the use of backup ground stations to support the mission in the event of a 
failure of the GPM-TDRSS communications link. In the event of this contingency situation, the data 
delivery requirements will be relaxed because of the somewhat infrequent station contacts and the 
short station contact times, nominally on the order of 7-minutes. To fully support this scenario, the 
ground site(s) would only need to have a standard router that supports both IP security and mobility 
protocols. However, while the real-time data would not always be flowing to all science users, the 
MOC would still provide the files for the complete set of science products. During the contact, the 
MOC would command the spacecraft to downlink the data at a rate up to 4 Mbps, depending upon 
the station supporting the ground contact. The downlink rate needs to be sufficient to allow 
transmission of all science and housekeeping files and real-time spacecraft data and to ensure that 
NACKs/ACKs can be sent to the spacecraft before the end of the contact. Whatever data are not 
successfully transmitted during the contact will be resent at the next available station contact. 

In this scenario, the GPM instruments continue to create the science data and the OBC will create 
the files corresponding to the data and put these files into the “hot directory”. These files will reside 



on-board the spacecraft until the spacecraft establishes a downlink with the MOC. When the 
spacecraft has a downlink established, the MDP server automatically begins transmitting the files. 


FUTURE EFFORTS 

The OMNI Project is tasked to complete several trade studies and prototyping efforts over the next 
year to provide additional input on how GPM could be designed to use a full IP implementation. The 
OMNI Project has another effort underway to demonstrate and support basic IP connectivity on the 
space link, mobile-IP routing, and a flight-based MDP system, on the Communication and 
Navigation Demonstration on Shuttle (C ANDOS) mission, which is scheduled to be tested in the 
summer of 2002. CANDOS has its own independent transceiver, which will be used to directly 
contact either ground stations or TDRSS, independent of the Shuttle communications system. These 
concepts are discussed in the paper “Space Communications Demonstration Using Internet 
Technology”!?]. 


CONCLUSIONS 

As previously described in this paper, the full use of an IP implementation for a space mission can 
be done with minimum risk. A frill end-to-end IP approach provides simple and flexible 
communications that manages all mission requirements. Technically, IP works fine in space; there are 
no showstoppers. The only remaining concern is simply the application of a standard engineering 
process with the engineering solution space enlarged. IP enables advanced mission concepts (e.g., 
collaborative science) and allows better alignment with industry standards and products. IP supports 
a simpler, yet more capable, overall mission design and enables a simpler operations solution. 

The OMNI Project has shown that a complete IP system not only can be done but also has been 
done. The OMNI Project has successfully completed several prototyping and demonstration 
activities using a total end-to-end IP-based architecture. The OMNI Black Sea mission employed an 
IP data communications approach to transmit live data during the 1999solar eclipse from the Black 
Sea. OMNI then followed up with the UoSat-12 mission and the laboratory OMNI Flatsat 
development. The OMNI Project is currently supporting the CANDOS mission. These approaches 
and results also are documented on the OMNI website [8], The next generation solutions are on the 
drawing board. The vision will include a full end-to-end IP solution that will evolve to support 
advanced mission concepts and profiles as depicted in Fig. 4, with levels of interoperability for 
future missions that have not been available in a cost-effective manner up to this time. This approach 
will make it easier for a constellation of satellites to directly communicate with one another, 
transferring data directly between the spacecraft rather than downlinking data, processing it on the 
ground and then uplinking the data. The use of commodity-level standard transport and routing 
protocols will reduce development costs, shorten schedules, and allow for earlier integration and test 
activities, thereby maximizing science return per dollar invested. 
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Figure 4 - Evolutionary Vision of IP for Mission Applications 
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